home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19971216-19980424
/
000039_news@newsmaster….columbia.edu _Fri Jan 2 20:50:38 1998.msg
< prev
next >
Wrap
Internet Message Format
|
1998-04-22
|
6KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id UAA27653
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 2 Jan 1998 20:50:38 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id UAA18573
for kermit.misc@watsun; Fri, 2 Jan 1998 20:50:37 -0500 (EST)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: K/2 Gotchas
Date: 3 Jan 1998 01:50:34 GMT
Organization: Columbia University
Lines: 95
Message-ID: <68k5ha$4kf$1@apakabar.cc.columbia.edu>
References: <TCPSMTP.18.1.2.-16.50.0.2375661496.4897539@kincyb.com>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:8205
In article <TCPSMTP.18.1.2.-16.50.0.2375661496.4897539@kincyb.com>,
<dallasii@kincyb.com> wrote:
: ...
: 2) My command files for exchanging email packages keep records
: of what happens in a file in RAM disk. At the end of the command file
:
: run TYPE MAILTEMP.TMP >> C:\QWK\RECORD.LOG
:
: is run to keep a permenant record of transactions.
: This command ran on MS-DOS 3.14 but was causing problems when I
: ran the command file on Kermit/2, with 'SYSxxxx File name too long'
: and such coming from the OS. I finally tracked this down to the need to
: change the command to
:
: run TYPE MAILTEMP.TMP >> C:\\QWK\\RECORD.LOG
:
: On MS-DOS Kermit 3.14, the single back slashes were permitted even though
: the documentation clearly states that a double back slash should be used
: when a back slash is desired where escaped substitution occurs.
:
One of the most aggravating thing about script languages -- all of them,
not just Kermit's -- is that certain characters inevitably become overloaded,
hence the annoying quoting rules. In the case of Kermit 95 and K/2, we try
our best to let you type pathnames with single backslashes or, for that
matter, with forward slashes instead of backslashes, but we can only do that
when Kermit itself is parsing the filename (even then it's guesswork at best;
if you type "c:\%a" is "\%a" a Kermit variable or an actual pathname?).
But obviously, Kermit can not parse the RUN command (at least not the part
past the word "RUN" -- it's just a text string to Kermit). So backslashes
here must be doubled.
The irony is that Windows 95, Windows NT, and OS/2 all support forward slashes
as directory seprators at the OS API level -- it is only their command shells
that get in the way. Why? Because they have the same problem we do: the
overloading of characters. In DOS-like command shells, "/" introduces a
"switch", so "dir /b" means "a brief directory listing" rather than a listing
of the files int the top-level B directory.
But yes, all of this is well documented. The C-Kermit manual even has a
section devoted to "Taming the Wild Backslash".
Some day we'll look back on all this and laugh.
: 3) When the command file got to the point where the mail package was being
: generated, the BBS generates a stream of
:
: ^H|^H/^H-^H\^H|^H/^H-^H\^H...........
:
: to indicate that things are not dead while the package is prepared.
: This seemed to spas out the command file when run in Kermit/2, but
: not MS-DOS Kermit. The problem was eliminated when the input buffer was
: increased from the default minimum size (256 bytes) to the maximum size
: (65,536 bytes). I noticed that there was a listing in BUGS.TXT that the
: "input buffer was too small". I don't think I have anything special about
: the input buffer for my MK 3.14, so I conclude that either
:
: a) the circular buffer works with MK 3.14 and not with K/2
:
That can't be true, or we'd have been pilloried by angry mobs years ago.
: or
:
: b) the ^H's effectively erase characters already in the input buffer
: in MK 3.14 but not with K/2
:
No. Bytes go into the buffer, no matter what they are (except NUL).
What is the syntax of your INPUT command?
: 4) Another problem was that a script seemed to stop, then fail on
: 'reinput' of a string that was obviously being recieved. The real problem
: turned out to be in an earlier 'input' command. The Gotcha! in this case
: was that besides going between versions of Kermit, there were two modems
: involved...
:
Well, this kind of script programming is a lot easier now that both K95 (K/2)
and MS-DOS Kermit support the MINPUT command (INPUT looks for Many things at
once). There is virtually no longer any need for REINPUT.
: 5) Another problem was brought on when a dialup
: script ran. Everything went OK until I went to connect mode.
: Then, as soon as anything was entered from the keyboard, K/2
: left connect mode back to command mode, the session froze up,
: the cursor went to lower left-hand corner and the session seemed to become
: unkillable. Any effort to stop the session would produce a message at the
: bottom of the screen, something to the effect of
: "!!! Recieved Kill Signal!!!", but the session lived on, hogging the
: COM port, still locked up until reboot.
:
If you can reproduce this ("!!! Recieved Kill Signal!!!" is not one of our
messages), you should contact kermit-support@columbia.edu and we'll see if
we can figure out what's what. Obviously Kermit should not hang, and you
should not need to reboot your PC to get the COM port back.
- Frank